home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / rfc / rfc607 < prev    next >
Encoding:
Text File  |  1991-04-20  |  8.4 KB  |  175 lines
  1. Request for Comments: 607                                 Mark Krilanovich
  2. NIC # 21255                                                   George Gregg
  3. references: RFC #542 UCSB                                       Jan  1974
  4.                                                       
  5.  
  6.                  Comments on the File Transfer Protocol
  7.  
  8.  
  9. There are several aspects of the File Transfer Protocol that constitute
  10. serious drawbacks. Some of these are quite basic in nature, and imply
  11. substantial design changes; these will be discussed in a later RFC.
  12. Others could be remedied with very little effort, and this should be done
  13. as soon as possible.
  14.  
  15. Following is a list of those problems that can be easily solved, together
  16. with their proposed solutions:
  17.  
  18. 1. Once a server has been told to be "passive" with regard to establishment
  19. of data connections, there is no way for the user to make him "active"
  20. again. SOLUTION: define a new command, with a command verb of "ACTV", to
  21. mean that the server is to issue a CONNECT rather than a LISTEN on the data
  22. socket. If the server is already "active", the command is a no op. "ACTV"
  23. is to have the same reply codes as "PASV".
  24.  
  25. 2. Design of an FTP server would be simpler if all command verbs were the
  26. same length, and design of an FTP user would be simpler if either all
  27. command verbs were the same length, or if multiple blanks were allowed
  28. following the verb. SOLUTION: replace the only three-letter verb, "BYE",
  29. with a four-letter one, such as "QUIT", and constrain future command verbs
  30. to be four letters long.
  31.  
  32. 3. The order of the handshaking elements following a file transfer command
  33. is left unspecified. After sending a STOR command, for example, a user
  34. process has no way of knowing which to wait for first, the "250 FILE
  35. TRANSFER STARTED" reply, or establishment of the data connection. SOLUTION:
  36. specify that the server is to send a "250" reply before attempting to
  37. establish the data connection. If it is desired to check if the user is
  38. logged in, if the file exists, or if the user is to be allowed access to
  39. the file, these checks must be made before any reply is sent. The text of
  40. the "250" reply would perhaps be more appropriate as "250 OPENING DATA
  41. CONNECTION", since it comes before actual data transfer begins. If the
  42. server wishes to send an error reply in the event that the data connection
  43. cannot be opened, it is to be sent in lieu of the "252 TRANSFER COMPLETE"
  44. reply.  
  45.  
  46. 4. Some hosts currently send an error reply on receipt of a command
  47. that is unimplemented because it is not needed (e.g., "ACCT" or "ALLO").
  48. Even though the text of the reply indicates that the command has been
  49. ignored, it is obviously impossible for a user process to know that there
  50. is no real "error". SOLUTION: require that any server that does not support
  51. a particular command because it is not needed in that system must return a
  52. success reply.
  53.  
  54. 5. There is no specified maximum length of a TELNET line, user name,
  55. password, account, or pathname. It is true that every system implementing
  56. an FTP server likely has different maxima for its own parameters, but it is
  57. nearly impossible for the writer of an FTP user (which must converse with
  58. many FTP servers) to construct an indefinite length buffer. Typically some
  59.  
  60.                                      -1-
  61. arbitrary maximum must be chosen. SOLUTION: specify a maximum length for
  62. TELNET lines, user names, passwords, account numbers, and pathnames. This
  63. is to be done after conducting a poll of serving sites concerning their
  64. individual maxima.
  65.  
  66. 6. The notion of allowing continuation lines to start with arbitrary text
  67. solves a minor problem for a few server FTP implementers at the expense of
  68. creating a major problem for all user FTP implementers. The logic needed to
  69. decode a multi-line reply is unnecessarily complex, and made an order of
  70. magnitude more so by the fact that multi-line replies are allowed to be
  71. nested. SOLUTION: assign a unique (numeric) reply code, such as "009", to
  72. be used on all lines of a multi-line reply after the first.
  73.  
  74. 7. Given that multi-line replies are allowed to be nested, the fact that
  75. the maximum allowed level of nesting is left unspecified creates a hardship
  76. for implementers of user FTPs. This hardship is somewhat easily solved on a
  77. machine that has hardware stacks, but not so for other machines. SOLUTION:
  78. specify a maximum level of nesting of multi-line replies.
  79.  
  80. 8. In blocked mode, the protocol states that "all end-of-record markers
  81. (EOR) are explicit, including the final one." This prohibits sending data
  82. between the final end of record and the end of file, but does not specify
  83. what the receiver of data is to do if this rule is broken. That is, should
  84. the intervening data be discarded or treated as a new (final) record?
  85. SOLUTION: specify that if an end-of-file marker is not immediately preceded
  86. by an end-of-record marker, the intervening data is to be discarded.
  87.  
  88. A major complaint about the protocol concerns the fact that the writer of
  89. an FTP user process must handle a considerable number of special cases
  90. merely to determine whether or not the last command sent was successful. It
  91. is admitted that the protocol is well-defined in all the following areas,
  92. but it is important to realize that the characteristic "well-defined" is
  93. necessary, but not sufficient; for many reasons, it is very desirable to
  94. employ the simplest mechanism that satisfies all the needs. Following is a
  95. list of those drawbacks that unduly complicate the flow chart of an FTP
  96. user process:
  97.  
  98. 9. Different commands have different success reply codes. A successful
  99. "USER" command, for example, returns a "230" whereas a successful "BYTE"
  100. command returns a "200". The concept that success replies should have an
  101. even first digit and failure replies an odd first digit does not apply, as
  102. "100, means success for "STAT", and "402" means failure for "BYTE".
  103. SOLUTION: specify that any command must return a reply code beginning with
  104. some unique digit, such as "2", if successful, and anything other than that
  105. digit if not successful.
  106.  
  107. 10. Some commands have multiple possible success reply codes, e.g., "USER",
  108. "REIN", and "BYE". It is undesirable for an FTP user to be required to keep
  109. a list of reply codes for each command, all of which mean "command
  110. accepted, continue".  SOLUTION: same as for (9.) above. The desire to
  111. communicate more specific information than simply "yes" or "no", such as
  112. the difficulty in the login procedure that some sites do not need all the
  113. parameters, may be solved by having, for example, "238" mean "PASSWORD
  114. ACCEPTED, YOU ARE NOW LOGGED IN", and "237" mean "PASSWORD ACCEPTED,
  115. ACCOUNT NOW NEEDED" The important point is that the idea of "command
  116. accepted" is conveyed by the initial "2", and that finer gradations of
  117. meaning can be deduced by the user process, if desired.
  118.  
  119.                                       -2-
  120.                                       
  121. 11. There are several types of replies that are extraneous from the point
  122. of view of a user FTP process, and their reply codes have no characteristic
  123. that makes them easily distinguishable.  For example, "010 message from
  124. operator" and "050 FTP commentary" are superfluous to a user process, and
  125. "000 announcing FTP" (in place of "300" greeting) is not. SOLUTION: specify
  126. that any reply that has meaning only to a human user and not to a user
  127. process must have a reply code beginning with a unique digit, such as "0".
  128. The continuation line reply code proposed in (8.) above falls into this
  129. category, and therefore must start with the same unique digit.
  130.  
  131. 12. The notion of a server sending a "000 announcing FTP" or a "020
  132. expected delay" immediately after completion of the ICP if input cannot be
  133. accepted right away is another instance of multiple reply codes having the
  134. same meaning to a user process.  SOLUTION: require that the server send a
  135. reply with a "020" reply code in the situation cited. If it is desired to
  136. communicate more detailed information, the text of the reply may used for
  137. this purpose.
  138.  
  139. In addition to the above mentioned weaknesses in the protocol, the
  140. following is believed to be a typographical error:
  141.  
  142. 13. Reply code "331" is cited as a possible success reply code for the
  143. commands "BYTE", "SOCK", "PASV", "TYPE", "STRU", "MODE", "ALLO", "REST",
  144. "SITE", AND "STAT". This reply code means "ENTER ACCOUNT" (if required as
  145. part of login sequence), and perhaps should be "332 LOGIN FIRST, PLEASE".
  146. This is especially indicated by the fact that "332" is not listed anywhere
  147. in the command-reply correspondence table.
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.                                       
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173.  
  174.  
  175.                                        -3-